-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Syntax for Capture Variables and Explicit Capture Polymorphism v2 #22902
base: main
Are you sure you want to change the base?
Conversation
`cap` is now a soft modifier and we abolish separate cap lists.
Neg test use-capset revealed that type param clauses are incorrectly parsed when a capset parameter has an annotation.
I think it would be good to open a thread on contributors to discuss the new syntax. That way, p[eople can weigh in with opinions and proposals. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM
Looking at the test cases I am now less sure this is the best syntax. In particular I find the We should try to get some representative test cases, evaluate how common we believe they will be, and compare different syntaxes with each other. That's what we did for the givens before we settled on one syntax. We could have that discussion thread here on the PR or on contributors. |
We discussed this. They are needed around all capture arguments and bounds of capture variables. The previous design allowed dropping them for singleton sets, but we didn't want it. It's regular, though I have to say, while patching the examples, I tended to subconsciously go back to braceless singletons from time to time only to be surprised by syntax errors... What should be the alternative for
🫡 on it! |
Plus added a test demonstrating branding and uses of upper and lower bounds.
Capture set variables `X^` are represented as regular type variables with a | ||
special upper bound `CapSet`. For instance, `Source` could be equivalently | ||
Capture-set variables `cap X` are represented as regular type variables within the special interval | ||
`>: CapSet <: CapSet^`. For instance, `Source` could be equivalently |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say the interval of a capture variable is: >: {} <: {cap}
, to hide the internal CapSet
.
In a separate paragraph, we can point out CapSet
is a special internal type to carry capture sets, and cap X
is de-sugared to X >: CapSet <: CapSet^
```scala | ||
def main() = | ||
// We can close over anything branded by the 'trusted' capability, but nothing else | ||
def runSecure[cap C >: {trusted} <: {trusted}](block: () ->{C} Unit): Unit = ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a fixed bound is a good example to illustrate the polymorphism...
Closes #22490
Builds on #22725
Supersedes #22758
This aim of this PR is reducing the clunkyness of the explicit capture polymorphism syntax following internal discussions.
syntax.md
.Add specialized syntax error messages for cap lists & co.(make separate issue)[C^]
syntax for good.Make cap members and lists pretty-printed (with option to turn off).(separate issue, let's wait for under-the-hood changes to the capset representation)